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(54) A method to forward a multicast packet 

(57) The invention concerns a method to forward a 
multicast packet (P) in a connectionless multicast sys- 
tem from an ingress node (N1) via a router (R3) to a 
plurality of destinations (D1; D2; D8). The method 
comprises the steps of 

a) storing by the router (R3) in a memory a relation 
between a value of a receiver update notification 
(RUN 1 ) and a predefined construction set (CS1), 
the predefined construction set (CS1 ) includes a set 
of next hops that includes one or more next hops 
(R6, R7) being determined according to local uni- 
cast routing information for each destination of a 
predefined set of destinations (D4 P D5, D8). The 
predefined set of destinations (D4, D5, D8) only in- 
cludes these destinations of the plurality of destina- 
tions for which the router (R3) is on a path to these 
destinations; and 

b) associating by the ingress node (N1) to a starting 
destination set (D1 , D2, „., D8) the value of the re- 
ceiver update notification (RUN1) and including by 
the ingress node (N1) the value of the receiver up- 
date notification (RUN1) in the multicast packet (P); 
and 

c) by the router (R3), upon reception of the multicast 
packet (P) that includes the value of the receiver 
update notification (RUN1), determining a prede- 
fined subset of destinations (D4, D8) and determin- 
ing for the predefined subset of destinations (D4, 
D8) a next hop (R6) of the set of next hops (R6, R7) 
according to the value of the receiver update notifi- 
cation (RUN 1) and according to the relation to the 



predefined construction set (CS1). The predefined 
subset of destinations (D4, D8) and the value of the 
receiver update notification (RUN1) are included in 
the new multicast packet (P) and the multicast pack- 
et (P) is forwarded towards the next hop. The pre- 
defined subset of destinations (D4, D8) includes 
these destinations of the plurality of destinations for 
which the next hop (R6) is on a path to these des- 
tinations. 
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Description 

[0001] The present invention relates to a method to 
forward a multicast packet in a connectionless multicast 
system according to claim 1 and to an ingress node and 
a router realizing such a method according to claim 7 
and to claim 8, respectively, and to an internet network 
including such an ingress node or such a router accord- 
ing to claim 10. 

[0002] Such a method is already known in the art, e. 
g. from the Article 'Datagram Routing for Internet Mufti- 
casting' written by Lorenzo Aguilar, SRI International , 
Menlo Park California, and published in the proceedings 
of Sigcomm84 in March 1984, ACM 
0-8791-136-9/84/006/0058 page 58 to 62. 
[0003] Therein a solution to the problem of multides- 
tination routing in internetworks is described. More par- 
ticular, at page 59, third paragraph, the so called 'multi- 
destination addressing' is described. Such an algorithm 
places all its destination addresses in an Internet Pack- 
et. During propagation, the packet is replicated at gate- 
ways, called hereafter routers, and the address list is 
partitioned among the newly created packets, according 
their next internet stop. In this way, at each router the 
next hop for each destination is determined and per next 
hop a new header is constructed that contains only 
these destinations for which that next hop is on the 
shortest path to these destinations. This approach is 
called in the claims connectionless multicast system. 
[0004] A problem outstanding with such a connection- 
less multicast system is however that the forwarding 
process in the different routers requires, a number of 
times, the consultation of the unicast routing table 
whereby this look-up and the re-construction of the 
packet headers consumes too much processing time. 
Hereby the wire-speed forwarding can not be achieved. 
[0005] An object of the present invention is to provide 
a method to forward a multicast packet in a connection- 
less multicast system from an ingress node via a router 
to a plurality of destinations that does not have the 
above problem of consuming too much processing for 
the number of look-ups to the unicast routing table and 
the re-construction of the packet headers. 
[0006] According to the present invention this object 
is achieved with the method of claim 1 which is realized 
by the ingress node and the router of claim 7 and claim 
8, respectively and by the internet network that includes 
such an ingress node and such a router of claim 10. 
[0007] Indeed, the object is achieved due to the fact 
that the method, according to claim 1, comprises the 
steps: 

a) storing by the router in a memory a relation be- 
tween a value of a receiver update notification and 
a predefined construction s t. The predefined con- 
struction set includes a set of next hops that in- 
cludes one or more next hops. The next hops are 
determined for each destination of a predefined set 



of destinations. The next hops are determined ac- 
cording to look-ups to local unicast routing informa- 
tion. The predefined set of destinations e.g. the des- 
tinations received within the header of a multicast 
5 packet includes only these destinations of the plu- 

rality of destinations for which the router is on a path 
to these destinations. 

b) associating by the ingress node to a starting des- 
tination set the value of the receiver update notifi- 

10 cation. Such a starting destination set includes each 
one of the plurality of destinations. The ingress 
node furthermore includes this value of the receiver 
update notification in the multicast packet in order 
to be forwarded together with the multicast packet; 

15 and 

c) by the router, upon reception of the multicast 
packet that includes the value of the receiver update 
notification, determining a predefined subset of 
destinations; and determining for the predefined 

20 subset of destinations a next hop of the set of next 
hops according to the value of the receiver update 
notification and according to the relation to the pre- 
defined construction set; and including in the multi- 
cast packet the predefined subset of destinations 

25 and the value of the receiver update number; and 
forwarding the multicast packet towards the next 
hop, the predefined subset of destinations includes 
these destinations of the plurality of destinations for 
which the next hop is on a path to these destina- 

30 tions. 

[0008] Indeed, in this way the ingress node puts the 
value of the receiver update notification in e.g. the des- 
tination address and uses this same number for the fol- 

35 lowing multicast packets whereby a router according to 
the present invention forwards the multicast packets ac- 
cording to the associated construction set in its memory. 
Each time the set of destinations changes, the ingress 
node indicates this to the downstream routers by updat- 

40 jng and using a new value for the receiver update noti- 
fication whereby the router is flagged to adapt the con- 
struction set by consulting, only then, the unicast routing 
table. 

[0009] It has to be remarked here that the use of a 
45 value of the receiver update number is not necessary in 
order to forward a multicast packet. Indeed, once a val- 
ue has been defined by the ingress node and has been 
forwarded to the routers, the value might be used to im- 
prove the forwarding process of the routers but is not 
50 essential to forward the multicast packets towards the 
different destinations. 

[0010] A further remark is that as well traditional rout- 
ers and routers according to the present invention might 
be used simultaneous in the network. Indeed, in the 
55 event of a traditional router that not works with a memory 
for storing the relations between receiver update notifi- 
cation and construction set, the router is still able to for- 
ward the multicast packets according to the priorart con- 
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nectionless multicast procedures. Such a router just ig- 
nores the inclusion of such a receiver update notification 
in the multicast packet. On the other hand, a router ac- 
cording to the present invention will use the presence of 
a value for the receiver update notification and is ena- 
bled to improve its forwarding process. 
[0011] Furthermore, it has to be remarked that the ex- 
pression 'is on a path to these destinations' is used in 
the application to mention the route from the ingress 
node to the destinations. Hereby it has to be understood 
that usual a shortest path is used for the routing of the 
multicast packets from the ingress node to the destina- 
tions. However the use of another predefined path from 
the ingress node to the different destinations that de- 
pends upon other kinds of criteria e.g. delay and band- 
width in order to be determined is not excluded by the 
present invention. 

[0012] It has to be remarked that a clear difference 
arises between a receiver update notification and a mul- 
ticast group number. Indeed, the receiver update notifi- 
cation is a reference to a construction set that includes 
information from the unicast routing tables but that is not 
essential to be used to forward the multicast packets. 
Whereas a multicast group number is a reference to in- 
formation in a multicast routing table that is essential to 
be looked up in order to forward the multicast packets. 
[0013] A further remark is that it has to be understood 
that the expression 'including e.g. a subset of destina- 
tions or a receiver update number' means that at least 
a reference to such destination of the subset of destina- 
tions or a reference to the receiver update number is 
included in the internet multicast packet at a predefined 
appropriate place. 

[0014] Yet, a remark is that an ingress node is defined 
as being the first node, for distributing the multicast 
packets, of a domain of nodes. Such nodes might be 
routers or hosts whereby an ingress node can be a host 
or a router. 

[0015] Furhtermore, it has to be remarked that ac- 
cording to step c) the multicast packet is forwarded to- 
wards the next hop. In fact, it is not the multicast packet 
but a replication i.e. a copy of the payload of the packet 
and a reconstruction of the header of the packet that is 
forwarded to the next hop. This is known according to 
the working of connectionless multicast system, but 
however, goes beyond the scope of the invention. The 
aim is that a replicate of the multicast packet is forward- 
ed to the next hops but is recalled, in order not to over- 
load the text, multicast packet, 

[0016] Yet, it has to be remarked that an implementa- 
tion with different next hops coupled to one output link 
of the router is not excluded e.g. an Ethernet link. 
[0017] A further feature of the present invention is de- 
scribed in claim 2. Herein it is described that in the event 
of more than one next hop being included in the set of 
next hops, the predefined construction set further in- 
cludes a destination relation between each next hop and 
the predefined subset of destinations. Hereby the step 



of determining the predefined subset of destinations is 
realized according to this destination relation. Indeed, 
since more than one next hop is involved to forward the 
multicast packet to, the partitioning of the destinations 
5 over the different constructed new headers must be de- 
termined. This might be realized according to the desti- 
nation relation. 

[001 8] Furthermore, according to claim 3, in the event 
of only one next hop being included in the set of next 

10 hops, the predefined subset of destinations might be de- 
termined by a received set of destinations being includ- 
ed in the received multicast packet. Indeed, since only 
one next hop is involved to forward the multicast packet 
to, determination of the newly subset of destinations to 

15 be included in the newly reconstructed header is real- 
ized by taking over the received set of destinations in 
the received multicast packet. 

[0019] Another characteristic feature is described in 
claim 4. In the event when the value of the receiver up- 

20 date notification and the predefined set of destinations 
was already included in a previously received multicast 
packet the set of next hops can be determined according 
to this set of destinations. The predefined construction 
set is constructed for each next hop according to unicast 

25 routing information and for each next hop a subset of 
destinations is determined i.e. destination relation. The 
relation between the value of the receiver update notifi- 
cation and the predefined construction set is established 
and hereby the step a) of the method of the invention is 

30 executed upon reception of this previously received 
multicast packet. 

[0020] It has to be remarked here that a previously 
packet is not necessary the multicast packet that was 
forwarded just before the actual multicast packet and 

35 that is is neither the first packet of the multicast session 
with this set of starting destinations. Indeed, other ele- 
ments might be important to decide during the connec- 
tionless multicast forwarding process the use of the re- 
ceiver update notification e.g. the actual load of the net- 

40 work or the processing load of the ingress node. The 
aim is that at a predefined moment a value for the re- 
ceiver update notification is determined and is associ- 
ated to a starting set of destinations. From then on, this 
value might be included, on regular or on rather irregular 

45 base, into the multicast packets in order to enable the 
routers to improve its forwarding process. 
[0021] Furthermore, claim 5 describes a situation 
whereby upon reception of a following multicast packet 
that includes a second value of the receiver update no- 

50 tification and that is associated to another starting des- 
tination set e.g. an extended starting destination set, the 
router has no relation stored in its memory. In this case, 
the following multicast packet is forwarded according to 
connectionless multicast procedures and step a) is ex- 

55 ecuted for this second value of the receiver update no- 
tification and a second construction set (CS2). This 
means that the unicast routing table is consulted to con- 
struct again a new construction set according to the set 
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of next hops and eventually according to a new subset 
of destinations. The construction set is saved and re- 
ferred by the newly received second value of the receiv- 
er update notification. The second value of the receiver 
update notification and the new subsets of destinations 5 
are included in the following multicast packet and are 
routed towards the different hops according to the usual 
connectionless multicast system. 
[0022] Finally, it has to be explained that as long that 
only one ingress node is included in the network to pro- 10 
vide the multicast packets, the relation between the re- 
ceiver update notification and the construction set can 
be determined unambiguous by reference to the value 
of the receiver update notification; However, in most net- 
works more than one ingress node is included to provide 15 
the service of multicast sessions. In such networks it is 
clear that the relation to a construction set is identified 
by a unique combination of a value of the receiver up- 
date notification and a network internet address of the 
ingress node. This is described in claim 6. 20 
[0023] It should be noticed that the term "comprising", 
used in the claims, should not be interpreted as being 
limitative to the means listed thereafter. Thus, the scope 
of the expression "a device comprising means A and B" 
should not be limited to devices consisting only of com- 25 
ponents A and B. It means that with respect to the 
present invention, the only relevant components of the 
device are A and B. 

[0024] Similarly, it is to be noted that the term "cou- 
pled", also used in the claims, should not be interpreted 30 
as being limitative to direct connections only. Thus, the 
scope of the expression "a device A coupled to a device 
B" should not be limited to devices or systems wherein 
an output of device A is directly connected to an input 
of device B. It means that there exists a path between 35 
an output of A and in input of B which may be a path 
including other devices or means. 
[0025] The above and other objects and features of 
the invention will become more apparent and the inven- 
tion itself will be best understood by referring to the fol- 40 
lowing description of an embodiment taken in conjunc- 
tion with the accompanying drawings wherein: 
[0026] Figure 1 represents a connectionless multicast 
system in an internet network and Figure 2 represents 
a block diagram of an ingress node coupled to a router 45 
according to the present invention. 
[0027] First, the working of the method of the present 
invention will be explained by means of a functional de- 
scription of the functional blocks shown in the figures. 
Based on this description, implementation of the func- 50 
tional blocks will be obvious to a person skilled in the art 
and will therefor not be described in further detail. In ad- 
dition, the principle working of the method to forward a 
multicast packet in a connectionless multicast system 
will be described. 55 
[0028] Referring to Figure 1, a connectionless multi- 
cast system in an internet network is shown. An ingress 
node N1 is coupled via seven routers R1, R2, R3, R4, 



R5, R6 and R7 to eight destinations D1 , D2, D3, D4, D5, 
D6, D7 and D8. The eight destinations are members of 
a multicast session. This means that the ingress node 
N1 distributes multicast packets to these destinations. 
In this way a multicast packet is forwarded to e.g. des- 
tination D4 via router R1, router R3 and router R6 re- 
spectively. More particular, the multicast packet is for- 
warded by the ingress node N1 and is in each router on 
its path replicated and further distributed to the different 
next hops i.e. the next routers on its way towards the 
set of destinations. 

[0029] The routing method used by the multicast sys- 
tem is connectionless multicast. This means that an in- 
ternet packet includes all the internet addresses of the 
multicast session members i.e. the set of destinations 

D1, D2 D8. It has to be remarked that although in 

the following paragraphs it is mentioned that 'destina- 
tions' are included in the header of a packet it has to be 
understood that the inclusion of the 'internet addresses 
of the destinations* is meant. In each router the next hop 
for each destination is determined and per next hop a 
new header is constructed. This new header contains 
only the destinations for which that next hop is on the 
shortest path to these destinations. In this way e.g. in 
router R3 a received multicast packet is duplicated and 
two new headers are constructed. A first new header 
contains destination D4 and D8 and is forwarded in a 
first duplicate of the internet packet to the next hop i.e. 
router R6. The other new header contains only destina- 
tion D8 and is forwarded in a second duplicate of the 
internet packet to the next hop i.e. R7. 
[0030] Referring to Figure 2 a block diagram of the 
ingress node N1 and the router R3 of the above men- 
tioned connectionless multicast system is shown. As it 
is known from Figure 1 , the ingress node N1 is coupled 
via router R1 to router R3. This is not repeated in Figure 
2 in order not to overload the figure. 
[0031] The ingress node N1 comprises associating 
means ASS and inclusion means INC coupled thereto. 
The inclusion means INC is coupled to an output of the 
ingress node N1 . 

[0032] The associating means ASS is implemented 
for this particular embodiment by a memory. The asso- 
ciating means ASS associates to a starting destination 

set e.g. D1, D2 D8 that includes each one of the 

members of the multicast session to a first value of a 
receiver update notification RUN1. The set of destina- 
tions D1 , D2 D8 and the first value RUN1 are for- 
warded by the associating means ASS to the inclusion 
means INC. 

[0033] The inclusion means INC includes, according 
to the connectionless multicast system, each internet 
address of each destination of the multicast session, 
called starting destination set, into the header of a 
present multicast packet R Furthermore, the inclusion 
means INC includes, according to the present invention, 
also the first value of the receiver update notification that 
is associated to this starting destination set into the 
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header of the present multicast packet P. 
[0034] It has to be remarked that, in order not to over- 
load Figure 2, only the header information that is rele- 
vant to the present invention is shown as being included 
in the multicast packet P. The header information that is 5 
not relevant to the present invention and the payload of 
the internet packet P are not shown. 
[0035] The router R3 comprises a memory MEM, a 
destination determiner DET-DES, a next hop determiner 
DET-HOP, a router inclusion means R-INC and a con- 10 
struction set determiner DET-CS. 
[0036] As already mentioned in a previous paragraph, 
an internet packet received at an input of router R3 is 
not the internet packet as distributed by the ingress node 
N. The header of the received internet packet was re- is 
constructed by router R1 (see Figure 1). The header of 
the internet packet that is received by router R3, in- 
cludes only these destinations for which R3 is on a path 
to these destinations i.e. D4, D5 and D8. This set of des- 
tinations is a predefined set of destinations D4, D5, D8 20 
since they are predefined by the previous router R1.. 
[0037] The construction set determiner DET-CS is 
coupled to an input of the router R3, to the memory MEM 
and to the next hop determiner DET-HOP. The next hop 
determiner DET-HOP is also coupled to the memory 25 
MEM and to the router inclusion means R-INC. The des- 
tination determiner DET-DES is coupled to the memory 
MEM and to the router inclusion means R-INC. The rout- 
er inclusion means R-INC is coupled to an output of the 
router R3. 30 
[0038] According to this particular embodiment, the 
construction set determiner DET-CS is included to de- 
termine a construction set in the event when it is re- 
quired. Such an event is e.g. when a particular value of 
the receiver update notification is present in the internet 35 
packet but, however, the value can not be found in the 
memory MEM. 

[0039] The construction set determiner DET-CS ex- 
tracts from the received internet packet the included val- 
ue of the receiver update notification RUN1 , the prede- 40 
fined set of destinations e.g. D4, D5 and D8 and the in- 
ternet address of the ingress node N1 . 
[0040] The construction set determiner DET-CS first 
checks whether an appropriate construction set e.g. 
CS1 is available in the memory MEM. This will be ex- 45 
plained in a further paragraph. 

[0041] In the event when no construction set is avail- 
able, the construction set determiner DET-CS looks up 
into its unicast routing table in order to determine for 
each destination of the predefined set of destinations a so 
next hop e.g. for D4, D5 and D8 the next hops R6, R7 
and R6 are, respectively, determined. 
[0042] Furthermore, for each determined next hop R6 
and R7 the subset of destinations is listed. The subset 
of destinations includes these destinations for which the 55 
next hop is on a path to these destinations. In this way 
the construction set determiner DET-CS determines a 
construction set for the received multicast packet. The 



construction set e.g. CS1 comprises for each deter- 
mined n xt hop e.g. R6 and R7 the determined subset 
of destinations D4, D8 and D5, respectively. 
[0043] The construction set CS1 is used in order to 
construct the new headers for the duplicated received 
multicast packet P and to forward these packets towards 
the respectively next hops. 

[0044] Furthermore, according to the present inven- 
tion, the construction set CS1 is also stored in the mem- 
ory of the router R3. The memory MEM stores the for- 
warded construction set e.g. CS1 of the construction set 
determiner DET-CS. It has to be remarked that the in- 
gress node N1 is not the only node that provides multi- 
cast sessions. In this way the value of the receiver up- 
date notification RUN1 might not be sufficient in order 
to identify the generated construction set CS1 in a 
unique way. Therefor the combination of the received 
value of the receiver number notification e.g. RUN1 and 
the internet address of the ingress node N1 are stored 
together with the generated construction set CS1 . It has 
to be remarked that according to this embodiment the 
construction set CS1 also includes a destination relation 
between each next hop and the determined subset of 
destinations. This is shown in figure 2 by a table included 
in the memory MEM. 

[0045] Furthermore, in the event when a multicast 
packet P is received by the router R3 that comprises a 
value of the receiver update notification e.g. RUN1 that 
can be found in the memory MEM no reconstruction of 
the construction set CS1 is executed. Indeed, according 
to the unique combination of the internet address of the 
ingress node N1 with the value of the receiver update 
number RUN1 the required construction set CS1 is de- 
termined in a unique way. Even more, the determined 
construction set CS1 was constructed in advance and 
can be used immediately. No looking up in the unicast 
routing table is required in order to forward this internet 
packet P. The newly headers can be constructed imme- 
diately. 

[0046] The destination determining means DET-DES 
determines a subset of destinations according to the 
destination relation in the memory MEM and forwards 
this information to the router inclusion means R-INC. 
[0047] The next hop determining means DET-HOP 
determines for each determined subset of destinations 
a next hop and forwards this information to the router 
inclusion means R-INC. 

[0048] In this way the router inclusion means R-INC 
includes for each next hop e.g. R6 in a replicated mul- 
ticast packet P' a subset of destinations e.g. D4 and D8 
and the associated value of the receiver update notifi- 
cation RUN1. The router inclusion means R-INC routes 
hereafter the packet P' towards an output of the router 
R3 according to the next hop R6. 
[0049] The principle working of the method to forward 
a multicast packet P in a connectionless multicast sys- 
tem from the ingress node N 1 via the router R3 to a start- 
ing destination set of eight destinations D1, D2 D8 
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is described in the following paragraph. 
[0050] Presume a situation wherein a previous multi- 
cast packet was already sent to the starting destination 
set D1, D2, D8. According to the present invention 
was the value of the receiver update notification RUN1 s 
forwarded together with the eight destinations in this 
previous packet to the starting set of destinations D1, 
D2 D8. This means that if this value RUN1 in com- 
bination with the internet address of the ingress node 
N1 was not known by the router R3, it will be known by 10 
the time when this previous packet passed the router 
R3. Herewith, the construction set CS1 is constructed 
by the router R3 in order to reconstruct the new headers 
and in order to forward the duplicated packets. Further- 
more, this construction set CS1 is also stored in the is 
memory MEM of the router R3. 

[0051] Now, when the multicast packet P of the same 
multicast session is forwarded by the ingress node N1 
to the same starting destination set D1, D2, D8 the 
same value RUN1 of the receiver update notification is 20 
included in the internet packet R Upon reception of the 
internet packet P by the router R3, the value of the re- 
ceiver update notification, the internet address of the in- 
gress node N1 i.e. the source address of the internet 
packet and the predefined destination set D4, D5, D8 25 
are extracted from the header of the multicast packet P 
by the construction set determiner DET-CS. The con- 
struction set determiner DET-CS controls the memory 
MEM upon the presence of the unique combination of 
the value of the receiver number notification RUN1 and 30 
the internet address of the ingress node N1. Since this 
combination was already stored together with the asso- 
ciated construction set CS1 at the moment when the 
previous packet passed the router R3 the combination 
is found back by the construction set determiner DET- 35 
CS, The destination determiner DET-DES and the next 
hop determiner are using the present information in the 
memory and forward this to the router inclusion means 
R-INC. The router inclusion means R-INC includes 
(RUN1 ; D4, D8) in a new packet header of a duplicated 40 
packet and forwards this packet to the router R6. The 
router inclusion means R-INC includes (RUN1; D5) in 
another new packet header of another duplicated pack- 
et and forwards this packet to the router R7. 
[0052] Presume a situation wherein an extra destina- 45 
tion D9 is added to the actual multicast session. This 

means that the starting destination set D1, D2 D8, 

D9 is extended i.e. is changed. The ingress node N1 
defines a second value RUN2 for the receiver update 
notification and associates this value to the newly de- so 
fined starting destination set D1, D2, .... D8, D9. The fol- 
lowing multicast packet to be forwarded by the ingress 
node N1 includes now the second value RUN2 of the 
receiver update notification together with the extended 
starting destination set D1 , D2, D8, D9. Upon recep- 55 
tion of this following multicast packet by the router R3, 
in a similar way as described in a previous paragraph, 
the construction set determiner DET-CS checks the 
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memory upon the presence of the combination N1 with 
RUN2. This time the combination is not found and the 
construction set determiner DET-CS is obliged to look 
up into the unicast routing table in order to determine a 
new construction set. So, in this way the router R3 is 
warned by the ingress node N1 that a new starting des- 
tination set D1 , D2, . ., D8, D9 is used and that most likely 
the received predefined destination set D4, D5, D8 and 
D9 is also changed. A new construction set CS2 is de- 
termined that includes a difference with the previous 
construction set CS1 of the extra destination D9 to the 
destination relation with router R6. This new construc- 
tion set CS2 is used to forward this actual following mul- 
ticast packet and is stored in the memory to be used for 
the next coming multicast packets. 
[0053] While the principles of the invention have been 
described above in connection with specific apparatus, 
it is to be clearly understood that this description is made 
only by way of example and not as a limitation on the 
scope of the invention, as defined in the appended 
claims. 



Claims 

1. Method to forward a multicast packet (P) in a con- 
nectionless multicast system from an ingress node 
(N1) via a router (R3) to a plurality of destinations 
(D1 ; D2; D8), characterized in that said method 
comprises the steps of 

a) storing by said router (R3) in a memory a re- 
lation between a value of a receiver update no- 
tification (RUN1) and a predefined construction 
set (CS1), said predefined construction set 
(CS1) includes a set of next hops that includes 
one or more next hops (R6, R7) being deter- 
mined for each destination of a predefined set 
of destinations (D4, D5, D8) according to local 
unicast routing information, said predefined set 
of destinations (D4, D5, D8) only includes these 
destinations of said plurality of destinations for 
which said router (R3) is on a path to these des- 
tinations; and 

b) associating by said ingress node (N1) to a 
starting destination set (D1 , D2 D8) that in- 
cludes each one of said plurality of destinations 
(D1 , D2, D8) said value of said receiver up- 
date notification (RUN1) and including by said 
ingress node (N1) said value of said receiver 
update notification (RUN1) in said multicast 
packet (P); 

c) by said router (R3), upon reception of said 
multicast packet (P) that includes said value of 
said receiver update notification (RUN1), deter- 
mining a predefined subset of destinations (D4, 
D8); and determining for said predefined sub- 
set of destinations (D4, D8) a next hop (R6) of 
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said set of next hops (R6, R7) according to said 
value of said receiver update notification 
(RUN1) and according to said relation to said 
predefined construction set (CS1); and includ- 
ing in said multicast packet (P) said predefined 5 
subset of destinations (D4 t D8) and said value 
of said receiver update notification (RUN1); and 
forwarding said multicast packet (P) towards 
said next hop, said predefined subset of desti- 
nations (D4, D8) includes these destinations of 10 
said plurality of destinations for which said next 
hop (R6) is on a path to these destinations. 



2. The method to forward a multicast packet (P) ac- 
cording to claim 1 , characterized in that in the event 15 
of more than one next hop being included in said 

set of next hops (R6, R7), said predefined construc- 
tion set (CS1 ) further includes a destination relation 
between said next hop (R6) and said predefined 
subset of destinations (D4, D8) whereby said step 20 
of determining said predefined subset of destina- 
tions (D4, D8) being realized by said destination re- 
lation. 

3. The method to forward a multicast packet (P) ac- 25 
cording to claim 1 , characterized in that in the event 

of one next hop being included in said set of next 
hops, said predefined subset of destinations (D4, 
D8) being determined by a received set of destina- 
tions being included in said multicast packet (P) up- 30 
on reception of said multicast packet (P). 

4. The method according to claim 1 , characterized in 
that in the event when said value of said receiver 
update notification (RUN1) and said predefined set 35 
of destinations (D4, D5, D8) was included in a pre- 
viously received multicast packet, determining said 
one or more next hops (R6, R7) according to said 

set of destinations (D4, D5, D8) in order to deter- 
mine said predefined construction set (CS1) and in 40 
order to determine thereby said relation between 
said value of said receiver update notification 
(RUN1) and said predefined construction set(CS1) 
and in order to execute thereby said step a) upon 
reception of said previously received multicast 45 
packet. 

5. The method according to claim 1 , characterized in 
that upon reception of a following multicast packet 

by said router (R3) that includes a second value of so 
said receiver update notification (RUN2) being as- 
sociated to another starting destination set (D1, 
D2, D8, D9) and having no relation stored in said 
memory of said router (R3), forwarding said follow- 
ing multicast packet according to connectionless 55 
multicast procedures and executing said step a) for 
said second value of said receiver update notifica- 
tion (RUN2) and a predefined second construction 



set (CS2). 

6. The method according to claim 1, characterized in 
that said relation being identified by a unique com- 
bination of a value of said receiver update notifica- 
tion (RUN1) and a network address of said ingress 
node (N1). 

7. An ingress node (N 1 ) to forward in a connectionless 
multicast system a multicast packet (P) via a router 
(R3) coupled thereto to a plurality of destinations 
(D1; D2; D8), characterized in that said ingress 
node (N1) comprises associating means (ASS) to 

associate a starting destination set (D1, D2, D3 

D8) including each one of said plurality of destina- 
tions (D1; D2; D3; D8) to a value of a receiver 
update notification (RUN1); and inclusion means 
(INC) coupled to said associating means (ASS) to 
include said value of said receiver update notifica- 
tion (RUN1) in said multicast packet (P) in order to 
be forwarded therewith and in order to thereby en- 
able said router (R3) to store in a memory a relation 
between said value of said receiver update notifica- 
tion (RUN1) and a predefined construction set 
(CS1), said predefined construction set (CS1) in- 
cluding a set of next hops that includes one or more 
next hops (R6, R7) being determined for each des- 
tination of a predefined set of destinations (D4, D5, 
D8) according to local unicast routing information, 
said predefined set of destinations (D4, D5, D8) on- 
ly includes these destinations of said plurality of 
destinations for which said router (R3) is on a path 
to these destinations; and in order to enable said 
router upon reception of said multicast packet (P) 
that includes said value of receiver update notifica- 
tion (RUN1) to determine a predefined subset of 
destinations (D4, D8); and to determine for said pre- 
defined subset of destinations (D4, D8) a next hop 
(R6) of said set of next hops (R6, R7) according to 
said value of said receiver update notification 
(RUN1) and according to said relation to said pre- 
defined construction set (CS1); and to include in 
said multicast packet (P) said predefined subset of 
destinations (D4, D8) and said value of said receiv- 
er update notification (RUN1); and to forward said 
multicast packet (P) towards said next hop, said 
predefined subset of destinations (D4, D8) includ- 
ing these destinations of said plurality of destina- 
tions for which said next hop (R6) is on a path to 
these destinations, 

8. A router (R3) to receive and to further forward in a 
connectionless multicast system a multicast packet 
received from an ingress node (N1) coupled thereto 
and forwarded by said ingress node (N1) via said 
router (R3) to a plurality of destinations (D1; D2; 
D8), charact rized in that said router (R3) compris- 
es memory means (MEM) coupled to an input of 
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said router (R3) to store a relation between a value 
of a receiver update notification (RUN1) and a pre- 
defined construction set (CS1), said predefined 
construction set (CS1) including a set of next hops 
that includes one or more next hops (R6, R7) being 5 
determined for each destination of a predefined set 
of destinations (D4, D5, D8) according to local uni- 
cast routing information, said predefined set of des- 
tinations (D4, D5, D8) only including these destina- 
tions of said plurality of destinations for which said 10 
router (R3) is on a path to these destinations, said 
value of said receiver update notification (RUN1) 
being associated by said ingress node (N1) to a 
starting destination set (D1, D2, D8) including 
each one of said plurality of destinations (D1, 15 
D2, .... D8) and being included by said ingress node 
(N1) in said multicast packet (P) in order to be for- 
warded to said plurality of destinations (D1; D2; 
D8); and destination determining means (DET- 
DES) to determine upon reception of said multicast 20 
packet (P) a predefined subset of destinations (D4, 
D8); and next hop determining means (DES-HOP) 
coupled to said memory (MEM) to determine for 
said predefined subset of destinations (D4, D8) a 
next hop (R6) of said set of next hops (R6, R7) ac- 25 
cording to said value of said receiver update notifi- 
cation (RUN1 ) and according to said relation to said 
predefined construction set(CS1); and router inclu- 
sion means (R-INC) coupled between said next hop 
determining means (DET-HOP) and an output of 30 
said router (R3) to include in said multicast packet 
(P) said predefined subset of destinations (D4, D8) 
and said value of said receiver update notification 
(RUN1 ) and to forward said multicast packet (P) to- 
wards said next hop (R6), said predefined subset 35 
of destinations (D4, D8) including these destina- 
tions of said plurality of destinations for which said 
next hop (R6) is on a path to these destinations. 

9. The router (R3) according to claim 7, characterized *o 
in that in the event of more than one next hop being 
included in said set of next hops (R6, R7), said pre- 
defined construction set (CS1) further includes a 
destination relation between said next hop (R6) and 
said predefined subset of destinations (D4, D8) and 45 
said destination determining means (DET-DES) is 
further included to determine said predefined sub- 
set of destinations (D4, D8) according to said des- 
tination relation. 

50 

10. An internet protocol network to forward a multicast 
packet (P) with a connectionless multicast system, 
characterized in that said internet protocol system 
includes at least any one of an ingress node (N1) 
according to claim 7 and a router (R3) according to 55 
any one of claim 8 and claim 9. 
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